Handheld portable data terminal having an integrated code reader for data entry and an event-driven touch-screen enabled graphical user interface

ABSTRACT

A handheld portable data terminal having an integrated code reader (for example, optical bar-code reader) for data entry and a touch-screen enabled graphical user interface (which may include virtual rolling keys, a scroll bar, virtual key pad, and the like) for interacting with a user to enter user-supplied information. In addition, the data terminal preferably includes a wireless communication interface for data communication with a remote computing device over a wireless communication channel. The data read by the integrated code reader (and possibly communicated to the remote computing device over the wireless communication interface) preferably includes product information, information identifying a medical patient, or information related a medical patient (such as personal information gathered upon admittance for care, information related to past medical history of the medical patient, and information related to vital statistics of the medical patient).

RELATED CASES

[0001] This Application is a Continuation of U.S. application Ser. No.09/241,214 filed Feb. 1, 1999; which is a Continuation of U.S.application Ser. No. 08/196,452 filed Feb. 14, 1994, now U.S. Pat. No.5,867,688. Each said patent application is assigned to and commonlyowned by Metrologic Instruments, Inc. of Blackwood, N.J., and isincorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The present invention relates in general to a system for dataacquisition and retrieval through the use of a user interface remotelylocated from the control system.

[0004] 2. Description of the Related Art

[0005] Today, most commercial businesses require field employees, suchas at points of sale, to fill out paper forms with data sets concerningindividual customers or products sold/manufactured. These reports arethen collected, compiled and assimilated at a central location and filedfor future access. Most modern businesses require this information to becontinuously updated and that the field personnel be afforded quickaccess thereto in order to reduce business costs, improve efficiency,increase accuracy, and the like. Heretofore, data sets concerningmatters, such as customer or product information, have been primarilycompiled through paper forms completed by field personnel and laterpossibly entered into some form of central database.

[0006] In the healthcare field, hospitals utilize a significant amountof data retrieval and acquisition, with respect to patient information.All data sets containing patient information (data field) such aspatient name (a data set header), date of birth, place of business,address, phone numbers, language, billing account number, socialsecurity number, drivers license number, and the like were written onpaper forms and maintained in a paper file, and optionally entered bythe hospital staff into a common database. Thereafter, the patientinformation was supplemented with information pertaining to their healthcondition, such as vital signs, fluid intake, fluid output and the like,which were written on different paper forms by a nurse and later keyedinto this common database. Similarly, when patients undergo testing, thetest results were manually keyed into the common database and/or writtenon forms stored in the patient's paper file.

[0007] An alternative example lies in the insurance industry in whichfield claims adjustors travel to the site of an insurance claim andevaluate the damaged property. These adjustors fill out multiple formsidentifying the damage and the insured person's general information. Forinstance, in an automotive accident the claims adjustor must describeeach problem with the insured car, such as dents, scratches, and thelike. These forms are later processed manually or keyed into a commondatabase, after which, the claimant ultimately is paid.

[0008] A substantial amount of data acquisition and retrieval is alsoutilized in factory environments. During the course of manufacturingvarious products, floor workers and quality review must completemultiple forms concerning a given production unit.

[0009] However, every business requiring significant amounts of dataacquisition and retrieval in its day-to-day business encounter similarproblems. First and foremost, a significant amount of the fieldoperative's time is required in filling out the corresponding paperwork,in which the potential for user error exists. Also, in systems usingpaper forms, the information must be ultimately transferred to anelectronic database, which provides a second opportunity for user error.Clearly, it would be advantageous to reduce the number of user entries,thereby reducing the likelihood of error.

[0010] Further, in many markets, field personnel at one locationtypically require information quickly from another field location. Forinstance, in a hospital environment, a doctor within the general wardmay require immediate information concerning a patient from theradiology department. However, the process under which the informationis written down and carried between departments is very slow. Similarly,doctors and nurses require immediate and accurate knowledge of specificprocedures to be followed with regard to particular patients. Pastsystems for maintaining individual patient procedures have provenineffective.

[0011] Moreover, one office within a business will typically requireinformation from another office which must be hand carried or which isunavailable after the closing hours of the second office. For instance,hospitals require lab testing results be hand-carried to doctors who maybe waiting for such results during the course of surgery. Also,typically doctors require clinical data after the clinics have closed.

[0012] The need remains in this field for an improved data acquisitionand retrieval system to address the problems and drawbacks heretoforeexperienced. The primary objective of this invention is to meet thisneed.

SUMMARY OF THE INVENTION

[0013] It is an object of the present invention to provide a dataacquisition and retrieval system which allows users immediate real timeaccess to all existing customer/product information.

[0014] It is an object of the present invention to provide a dataacquisition and retrieval system which affords users access to wirelessremote data terminals.

[0015] It is an object of the present invention to minimize the dataretrieval time by reducing the necessary information transmitted betweenhandheld units and the corresponding communications server.

[0016] It is another object of the present invention to minimize thedata necessary for transmission by synchronizing operation within eachhandheld unit and a corresponding communications server, suchsynchronization including the minimization of header information foreach transmission and the transmission of a command case code useddirectly by the command server to access a designated database.

[0017] It is another object of the present invention to provide a userinterface which minimizes user error.

[0018] It is another object of the present invention to provide a userinterface which utilizes an event driven architecture to allow dataentry through a touch pad.

[0019] It is another object of the present invention to provide an userinterface which is easily operated by using a touch pad which presents ascroll bar, rolling keys and icons for data entry.

[0020] It is another object of the present invention is to provide anuser interface which allows for the scanning of bar codes to identifyparticular customers or products.

[0021] These and further objects will become more apparent from thedrawings and detailed description hereafter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The objects and features of the invention noted above areexplained in more detail with reference to the drawings, in which likereference numerals denote like elements, and in which:

[0023]FIG. 1 is a block diagram of an overview of a data acquisition andretrieval system according to the present invention;

[0024]FIG. 2 illustrates a block diagram of a handheld interfaceaccording to the present invention;

[0025] FIGS. 3(a)-3(d) illustrate exemplary display screens shown on thehandheld interface according to the present invention;

[0026]FIG. 4 illustrates the main processing loop by which the handheldinterface monitors and responds to events selected by the user;

[0027]FIG. 5 illustrates the processing sequence of the handheldinterface while displaying a patient information screen;

[0028]FIG. 6 illustrates the processing sequence of the handheldinterface to initiate the patient information screen;

[0029] FIGS. 7(a) and 7(b) illustrate the processing sequence of thehandheld interface while displaying a patient input screen;

[0030]FIG. 8 illustrates the processing sequence of the handheldinterface to initiate the patient input screen;

[0031]FIG. 9 illustrates the data structure of the packets transmittedbetween the handheld interface and the communications server;

[0032]FIG. 10 illustrates the processing sequence undergone by thehandheld interface to write data packets to the communications server;

[0033]FIG. 11 illustrates the processing sequence by which thecommunication server reads packets transmitted from the handheldinterface;

[0034]FIG. 12 illustrates the processing sequence by which thecommunication server parses through a short header structure within anincoming packet to build the input buffer;

[0035]FIG. 13 illustrates the processing sequence by which thecommunication server parses through a long header structure within anincoming packet to build the input buffer;

[0036]FIG. 14 illustrates the processing QUEUE sequence to movecompleted messages to the processing QUEUE;

[0037]FIG. 15 illustrates the processing sequence by which thecommunication server generates the processing queue;

[0038]FIG. 16 illustrates a block diagram of the RAM section of thehandheld interface;

[0039]FIG. 17 illustrates a block diagram of the communications server;

[0040]FIG. 18 illustrates an alternative data entry display for thehandheld interface; and

[0041]FIG. 19 illustrates the processing sequence of the command serverto process and transmit message lists.

DETAILED DESCRIPTION OF THE INVENTION

[0042] Overview

[0043]FIG. 1 illustrates a data retrieval/acquisition system accordingto the present invention generally illustrated by the reference numeral1. The instant system 1 includes a master server 2 which communicateswith multiple remote input units 4 through a communications bus 6. Eachinput unit 4 includes a communications server 12 directly connected to acommand server 14 and data bases 16. Each remote communications server12 interactively communicates with one or more handheld user interfaces8 while located within a predefined region 5 proximate thereto. Thisinteractive communication is conducted through a wireless dedicatedcommunication channel, such as upon an infrared carrier signal.

[0044] The communications server 12 controls all interaction between thehandheld interfaces 8, the command servers 14, and the communicationsbus 6. The command servers 14 control direct access to the databases 16.The command servers 14 may implement any conventionally known IOmanagement system, such as Pro-Tree (version 2.0), SQL or Paradox. Thecommunications server 12 communicates with each handheld interface 8through a unique communications protocol (hereafter referred to as theHandheld-Server Protocol). The communications server 12 communicateswith the command servers 14 through a unique protocol (hereafterreferred to as the Message List Protocol).

[0045] As explained below, the communications server 12 synchronizes itsoperations with those of the handheld interfaces 8 to minimize theexcess data necessary for each transmission therebetween. Thecommunications server 12 and interface 8 also utilize shorthand codevalues to identify constantly transmitted information, such as commands,user IDs, database IDs, and the like. By synchronizing operation of thehandheld interface 8 and the corresponding communications server 12, theinstant system is able to avoid the need to transmit the user ID, time,date, authorization code, and the like during every transmission.

[0046] During operation, the user enters data at the handheld interface8, the data is transmitted to the communications server 12 and storedinternally within the database 16. Data may also be entered directlyinto the communications server 12. Similarly, the user may request datapreviously submitted, in which case the communications server 12accesses the corresponding database 16, through the command server 14,and transmits the necessary desired information to the requestinghandheld interface 8. Throughout operation, a backup copy may bemaintained within the master server 2 for every remote database 16.Additionally, the user may request, via the handheld interface 8, datastored within a remote input unit 4 other than the data in the databasesdirectly connected to the receiving communications server 12. In such acircumstance, the corresponding communications server 12 would acceptthe request from the handheld interface 8, determine that the desiredinformation is stored within a remote database and request suchinformation through the communications bus 6 from the communicationsserver 12 containing the corresponding database. Thus, thecommunications bus 6 also allows data to be transmitted betweencommunications servers 12 and between handheld interfaces 8 (such aswhen one doctor is requesting information from another doctor).

[0047] By way of example only, the instant acquisition/retrieval system1 may be utilized within a healthcare facility wherein doctors, nurses,and staff utilize the handheld interfaces 8 to record and obtain patientinformation. These persons may be assigned different privileges whichwould allow varying levels of access to data. In this environment, eachcommunications server may be located within a different ward or testinglaboratory. Thus, a doctor in a general ward may need to send a messageto, or obtain information from, a doctor or nurse in radiology. To doso, the doctor would transmit a request through the handheld interface8, with the request being received and decoded in the general ward'scommunications server 12. The source/receiving communications serverdetermines the appropriate destination communications server thatcorresponds to the destination handheld interface, into which thedestination doctor or nurse has signed on. The desired message istransmitted to the radiology server, and to the corresponding handheldinterface which queries the user through audio, video, or vibratingmeans. In a similar manner, the user within radiology may transmit aresponse through the corresponding radiology and general wardcommunications servers 12 to the requesting doctor's handheld interface8. Also, lab data may be quickly transmitted to a surgeon during anoperation.

[0048] The instant acquisition/retrieval system 1 also allows doctors,nurses, and staff members immediate access to clinical data, even afterclinic hours are closed. To do so, the user merely enters a requestthrough his/her handheld interface 8, which is transmitted through thecorresponding communications server 12 to the clinical communicationsserver 12. The necessary clinical data is obtained from the clinicaldatabase and returned along the communications bus 6. By way of example,the data acquisition/retrieval system 1 of the healthcare facility maybe connected to similar systems via an ethernet connected between themaster servers 2.

[0049] The handheld interfaces 8 are used to enter all patientinformation such as personal information upon admittance, past medicalhistories, vital statistics throughout their stay in the hospital, andthe like. For instance, these vital statistics may include systolic,diastolic, pulse, temperature, and respiratory information. Similarly,the handheld interface 8 may be used to enter information concerning thepatient's fluid intake and output.

[0050] As will be explained below, the instant dataacquisition/retrieval system 1, also allows a user to carry a handheldinterface 8 between regions (see the dashed line 5 in FIG. 1) dedicatedto each communications server 12. Optionally, when this occurs, thehandheld interface 23, is considered to have signed off with the oldcommunications server (as illustrated by the dashed line 22).Thereafter, the handheld interface 23 must be signed onto the newcommunications server (as illustrated by the line 24) before it may beused for data entry.

[0051] The manner by which these objects and functions is achieved willbecome clear in connection with the following explanation of each moduleof the present invention.

[0052] Handheld Interface

[0053]FIG. 2 generally illustrates a block diagram of a handheldinterface 8 having a display screen 30 which may be back-illuminated andwhich is controlled by a CPU 32 to display desired information thereon.The display screen 30 also functions as a touch pad and is sensitive touser contact. When contacted, the display screen 30 outputs a signal tothe CPU 32 identifying the exact location of the contact therewith. Thehandheld interface 8 further includes a memory module 34 which storessoftware to control processing of the CPU 32 and which temporarilystores data received from, and transmitted to, the correspondingcommunications server 12. The CPU 32 controls an IR interface 36 tocontrol data transmissions to and from the communications server 12. Abar code reader 37 is included to allow the user to enter customer orproduct information from a bar code, such as customer/patient ID and thelike.

[0054] As explained below, the handheld interface 8 operates as an“event driven” device wherein the touch screen 30 is drawn to display adesired arrangement of virtual regions. Each region is assigned a uniqueidentifier. The handheld interface 8 recognizes each contact by a useras an event. The contact/event is recognized with respect to thecorrespondingly defined region and the region identifier is returned.Thereafter, the CPU 32 identifies the necessary course of action basedupon this identifier.

[0055] As illustrated in FIG. 3, during operation the CPU 32 may displaya variety of menus, graphs, and the like upon the touch screen 30.Within each display, the CPU 32 defines virtual regions which correspondto predefined processing sequences. The user initiates a desired eventsequence by contacting the preferred region corresponding to the event.To facilitate the user interaction therewith, the CPU 32 providesmultiple manners in which the user may enter and retrieve data. Asillustrated in FIG. 3(a), the CPU 32 draws a main menu 38 on the screen30 and defines multiple menu selections 40 therein (see the flowchart ofFIG. 10). Each menu selection 40 overlays and corresponds to a virtualevent region 42 corresponding to a different event/case. Every screen 30is displayed with an escape key 43 which allows the user to escape backto a previous function/screen or back to the main menu.

[0056] When implemented in a healthcare application, as illustrated inFIGS. 3a-3 d, when the user selects a vitals event region 44, the CPU 32recognizes it as such and processes a corresponding event sequence (seeFIG. 13).

[0057] As illustrated in FIG. 3c, the vitals input screen 60 (alsoreferred to as the data I/O screen) displays current patient informationin the patient field 62, such as the patient's name, social securitynumber, status, and the date upon which the vitals were last updated.The vitals input screen 60 illustrates the last current vitals (datasets) as shown in the systolic field 46, diastolic field 48, pulse field50, temperature field 52, and respiratory field 54 (collectivelyreferred to as data fields). The touch screen 30 allows the user toactivate a desired vital sign field by selecting a corresponding icon46, 48, 50, 52, and 54, respectively. Located immediately above eachicon is the current value for the corresponding vitals field. Thiscurrent value is also displayed within three rolling keys along side ofthe icon (the rolling keys are designated by the reference numeral 56).The patient's systolic vital sign field is active in FIG. 3c, asevidenced by the inverted rolling keys 56. Proximate the rolling keys 56is a scroll bar 58 for illustrating in a bar format the current value ofthe active vital sign field (i.e., systolic) which is inverted to thecurrent level (130).

[0058] To enter new patient vitals, the user may do so in multiple ways.First, the user may update the patient's systolic vitals byconsecutively contacting each rolling key 56 to be incremented. Eachrolling key continuously increments, such as from 0 to 9 and then backto 0. Alternatively, the user may enter patient vitals information bycontacting the scroll bar 58 at the desired position. In accordance withthe flowchart of FIG. 13, when the user contacts the scroll bar 58, thebar is updated to reflect the newly entered value. If the user dragshis/her finger along the scroll bar 58, the CPU 32 will continuouslyupdate the level thereof to reflect this movement of the finger. The CPU32 updates the corresponding rolling keys 56 for the active field (i.e.,the systolic field as illustrated in FIG. 3(c)). The user may draghis/her finger across the scroll bar 58 until the desired value isdisplayed in the rolling keys 58, at which time the user releases thescroll bar. The user may activate a different vital sign field (i.e.,change the mode) by selecting the corresponding icon (46, 48, 50, 52,and 54).

[0059] The vitals input screen 60 further includes change function keys64 which afford the user's direct access to displays, graphs, screensand the transmit function. More specifically, the vitals input screen 60allows the user direct access to the fluids input screen (not shown) forthe current patient by pressing the fluids function button 66.Alternatively, the user may view the selected vital sign field (e.g.,systolic field) in a graph format by selecting the view graph button 68.The vitals input screen 60 further includes a transmit informationbutton 70 which the user selects once a patient's new vital informationhas been entered. When the transmit button 70 has been pressed, the CPU32 transmits the updated patient information to the communicationsserver 12 in a format described below.

[0060]FIG. 3(b) illustrates a graph corresponding to the presentpatient's systolic vitals which is displayed when the view graph button68 is selected.

[0061]FIG. 3(d) illustrates a patient inquiry screen 74 selected fromthe main menu 38 (also referred to as the data set inquiry screen). Thepatient inquiry screen 74 displays a scrolling text window 78 whichexhibits the currently selected patient's name (data set header) andthose names alphabetically proximate thereto. Along one side of thescroll text window 78 is positioned a scrolling bar 80 which includes anidentifier 82 designating the position of the currently selectedpatient's name within a master alphabetical list. The user may scrollthrough the patient list by contacting the scrolling bar 80 at a desiredlocation therealong. The top and bottom of the scrolling bar 80corresponds to the beginning and end, respectively, of the list ofpatient names stored within the handheld interface 8.

[0062] The patient inquiry screen 74 also includes a virtual keypad 76which allows the user to enter the name of a desired patient. As theuser selects each letter of the desired patient's name, the CPU 34automatically performs a search upon the entered letters and updates thescroll text window 78 correspondingly. As the user enters additionalletters, the CPU 32 concatenates these letters to the end of the searchstring it uses and again updates the scrolling text window 78. Thepatient inquiry screen 74 also includes function buttons 64 along abottom thereof to allow the user to automatically jump to an alternativescreen. A scan button 77 is included to allow the user to read bar codedata from a patient's wrist band, such as patient ID.

[0063]FIG. 18 illustrates an alternative scroll bar implementation whichmay be used to allow the user to enter alphanumeric information. Forinstance, the CPU 32 may control the display screen 30 to illustrate adisplay field 90 and one or more scroll bars 92. The scroll bar 92 maybe defined such that one end corresponds to the letter A while theopposite end corresponds to the letter Z. The CPU 32 would definemultiple regions along the length of the scroll bar 92, each regioncorresponding to one letter of the alphabet. When the user contacts thescroll bar 92, a letter corresponding to the touched regions isdisplayed in a first location 94 of the display field 90.

[0064] As the user drags his/her finger along the scroll bar, the letterdisplayed within the first location 94 will vary corresponding to thecurrently selected region. Once the user removes his/her finger from thescroll bar 92, the last identified region is designated as the correctletter and entered in the first location 94 of the display. When theuser again contacts the scroll bar 92, the CPU 32 operates to display acorresponding letter in the second field location 96 of the displayfield 90.

[0065] If it is desirable to enter numerals within the display field 90,the CPU 32 may also draw a second scroll bar 98 upon the display screen30. The first end of the second scroll bar would represent a 0 while thesecond end of the scroll bar 98 would represent a 9. The user wouldenter numerals in the display fields 90 in the same manner as discussedabove with respect to letters. Optionally, a single scroll bar may beprovided for letters and numerals with function buttons 100 and 101being used to assign letters or numerals to the scroll bar.

[0066]FIG. 15 illustrates the RAM section 35 of the memory within thehandheld interface 8. The RAM memory 35 includes a patient informationsection 200 for storing a list of patient names (data set headers) andpatient identifiers (data set identifiers) associated with the presentuser of the handheld interface 8. The RAM memory 35 also includes aworking space 202 for storing all other information entered by the userand transmitted between the handheld interface 8 and the communicationsserver 12. Each time the CPU 32 transmits a request to thecommunications server 12 for patient information, the CPU 32 redefinesthe current data structure within the working space 102 to correspond tothe expected format of the return data from the communications server12.

[0067] By way of example only, when the CPU 32 requests patient vitals,it expects the returned data to include, in a preset order, thepatient's social security number, date on which the patient vitals werelast updated, and the most recent systolic, diastolic, pulse,temperature and respiratory values. The CPU 32 sets up fields within theworking space 202 for each of these values. When the returned data isreceived, the CPU 32 parses through the returned packet and assignsbytes therefrom to the desired field in the working space 202.

[0068] The RAM 35 further includes a temporary buffer for storingincoming and outgoing packets of information which are to be transmittedto and which are received from the communication server 12. The CPU 32moves data from the RAM 35 into the temporary buffer 204 immediatelybefore transmitting this information and adds a packet header 206thereto.

[0069] FIGS. 4-8 illustrate the processing sequence by which the CPU 32controls the main menu, vital sign patient/data set input screen and thepatient information screen (FIGS. 3a-3 d).

[0070] Generally, during operation the CPU 32 loops through one of twoprimary case/event handling loops (FIG. 4). The first case/event loopoperates to draw the main menu (FIG. 3a) and to handle events chosenfrom the main menu. When an event occurs which corresponds to a definedkey region within the main menu, a corresponding event identifier isreturned as the calling identifier. A return code is set equal to thiscalling identifier and the return code is checked against a predefinedvalue (0). If the return code is non-zero, processing flow enters thesecond primary loop to call the corresponding event handling function.The second primary loop corresponds to processing in which a menu otherthan the main menu is displayed (FIGS. 3b-3 d). During this second loop,a code which identifies the next function to be performed iscontinuously checked. When the code equals zero, processing returns tothe main loop. When the code is a nonzero value, the correspondingfunction is called. Once each function is completed it returns a codeidentifying the next function to be performed by the user. Thisconfiguration reduces the memory requirements by reducing the levels offunctions to be called, thereby reducing the necessary stack space.

[0071]FIG. 4 generally illustrates the processing undergone by thehandheld interface 8 when the user initiates the first session (i.e.,when the user first logs in). When a session is initiated the handheldunit prompts the user for the user's ID and password (step 1602). Next,a packet is constructed in the temporary buffer 204 which contains along header 206 structure and having a data section including the userID and password (step 1604). This packet is transmitted (step 1606) anda validation code therefor is waited upon. If the validation code is notreceived (step 1608) processing returns to step 1602 in which the useris reprompted for the ID and password. If a validation code is received,processing continues to step 1610 in which a return code is set toindicate that processing should move to the patient inquiry module.Thereafter, the return code is tested to determine whether it equalszero (step 1623). If the return code equals zero, processing returns tostep 1614 in which the main menu is redrawn.

[0072] After this initial login sequence is completed, flow enters themain event handling loops. First, a main menu is drawn and key regionstherein are defined in steps 1612 and 1614, after which the system waitsfor an event to occur (step 1616). Once an event occurs, it isdetermined whether the event is within a defined menu regions 42 (step1618) (i.e., whether the user has touched the display screen 30 at alocation corresponding to a menu selection 40). If not, processing loopsback to wait for the next event. If so, an event identifier is obtainedfor the key region in which the event occurred (step 1620). Next, anevent handling function corresponding to the event identifier is called(step 1622). Thereafter, processing waits for a call identifier returnedfrom the called event handling function. A return code is set equal tothe call identifier (step 1623) and the return code is tested in step1624 and if zero, processing returns to the initial step 1612 toredefine and redraw the main menu. If the return code does not equalzero, the process determines that the user has selected another functionbesides displaying the main menu. Thus, the event handling functioncorresponding to the non-zero return code is called (step 1626).Thereafter, the main event handling loop waits for the called functionto return a call identifier which is tested in step 1624.

[0073]FIGS. 5 and 6 illustrate the process undergone when the patientinformation screen 74 is selected to be displayed (such as during thewake up function or when called by the user). First, an initializationroutine is called in step 1700 (steps 1710-1720 in FIG. 6). Thisinitializing process begins by determining whether the handheldinterface 8 includes a list of patient names (data set headers) and IDs(step 1710). If this list does not exist (such as when the handheldinterface has initially been woken up), the unit constructs andtransmits a packet to the communications server 12 requesting thepatient list associated with the currently signed-in user (step 1712).The communications server 12 receives this packet, identifies the userID, and requests the appropriate information from the command server 14.Thereafter, the appropriate database 16 is read and the patient list forthe user is transmitted back to the handheld interface 8. After theinterface 8 sets up the data structure in the patient memory 200 for thepatient list (step 1714), it waits for the returned patient list (step1716). Once the patient list (name and ID) is received, it is stored inthe patient memory 200.

[0074] The handheld interface 8 may not include sufficient display spacein the scrolling text window 78 to show an entire patient's name. Thus,the patient memory section 200 will only include sufficient memory tostore the maximum number of characters which may be displayed for asingle patient name upon the screen. Once the patient list is stored,the patient screen format is displayed (step 1718) as illustrated inFIG. 3d. Next, the patient names are displayed in the scrolling textwindow 78 (step 1720) (FIG. 3d). When the patient list is too long to becompletely displayed within the scrolling text window 78, a defaultportion thereof is displayed. Next, the system waits for an event (step1722, in FIG. 6) and when one occurs, an event identifier is assignedthereto.

[0075] The event identifier is passed to a case/event statement whichincludes every possible valid value for the event identifier. By way ofillustration, processing will continue along one of six possibleprocessing paths to blocks 1724, 1726, 1728, 1730, 1750 or 1756,depending upon which event occurred. When event 1724 occurs (i.e., theuser presses the escape icon), the system returns a zero callingidentifier to the main loop (thereby indicating that no new eventhandling function has been selected). If the event indicates that theuser has touched the scrolling bar 80, processing flows to box 1726 inwhich the system determines the exact location of the event (step 1732).This location is correlated with a pointer that is used as an index intothe patient list to identify the new patient to be displayed in thescrolling text window 78. Once the event location is determined, thepointer into the patient list is updated and the scrolling text window78 is redrawn to display the name of the selected patient and a limitednumber of patient names surrounding the selected name (step 1734).

[0076] Next, the scrolling bar 80 is updated to move the identifier 82to a new position identifying the relative location of the indexedpatient within the overall patient list (step 1736). Thus, if the firstpatient is selected, the identifier 82 is redrawn at the top of thescrolling bar 80, and if the last patient is selected, the identifier 82is drawn at the bottom of the scrolling bar 80. If the event isidentified as occurring within the scrolling text window 78, processingflows to step 1728. Specifically, the location of the event is againidentified (step 1738) relative to the names currently displayed. Thename closest to the event is identified as the selected patient.Thereafter, the pointer into the patient list is updated to index thenewly selected patient name (step 1740). This name is displayed in thecenter of the scrolling text window and, optionally, may be inverted incolor (step 1740). The identifier 82 within the scrolling bar 80 is alsoredrawn to properly identify the new position of the selected patientwithin the patient list (step 1740).

[0077] If the keypad 76 is touched, processing flows to block 1730, atwhich the letter is identified which corresponds to the region touched(step 1742). This selected letter is added to a temporary patientsearching string within the work space memory 102 (step 1744). Thisletter is added to a search string (which is empty until the firstletter is selected). Thereafter, the processor conducts a search basedupon the search string into the patient list to identify the name mostclosely corresponding to the letter(s) selected from the virtual keypad76 (step 1746). If a search string exists (i.e., the user has alreadyentered some letters) the newly selected letter is concatenated onto thesearch string and a new search is conducted upon the text strings withinthe patient list to find the first text string which is greater inalphabetic value than (i.e., closest to) the search string. The pointeris set to the closest patient name and the scrolling text window 78 andthe scrolling bar 80 are updated (steps 1746 and 1748). If the userwishes to delete a letter from the search string, he/she simply pressingthe delete region key.

[0078] If the user selects the scan region 77, processing flow moves toblock 1750. The bar code scanner is read to obtain the bar code scannedby the user (step 1752) (this bar code may appear on a patient's wristband and the like). The bar code includes the patient ID, which is usedto find the patient name within the patient list (step 1754). Next, thepointer into the patient list is updated (step 1756) and the scrollingtext window 78 and scrolling bar 80 are redrawn (step 1758).

[0079] Once the user has selected a desired patient, the user may escapefrom the patient inquiry screen by pressing the escape icon 43 in theupper left corner or by selecting one of the function 64 buttons at thebottom of the screen (step 1760). As illustrated in FIG. 3d, the usermay escape to the main menu, review a patient's information completerecord or review the patient's vitals. If the user presses one of thechange function buttons 64 at the bottom of the screen, thecorresponding event identifier is evaluated to determine which functionkey the user has selected (step 1762) and the corresponding return codeis returned to the main processing loop in FIG. 16 (step 1764).

[0080]FIGS. 7a, 7 b and 8 illustrate the processing sequence undergoneby the handheld interface 8 when the vitals/data input/output handlingfunction is chosen (i.e., when a user desires to enter patient vitals).First, the display screen is cleared (step 1800) and the vitals (dataI/O) format is drawn upon the screen (step 1802). Similarly, the keyregions are defined which correspond to each even identifier. Next, itis determined whether the workspace memory contains vitals for aselected patient (step 1804). If not, the processor constructs andtransmits a packet (step 1806) requesting patient vitals. Thereafter,the workspace memory 202 is set up in the data structure correspondingto patient vitals (step 1808). Thereafter, the handheld interface waitsfor the returned patient vitals, receives these vitals in one or morepackets and disassembles the packets and stores the patient vitals inthe workspace (step 1810). Next, the processor draws the patient vitalsonto the screen (step 1812) and sets the default mode to a predeterminedfield (e.g., systolic field). The vitals for the default field are drawninto the scroll bar (step 1814) and the default rolling keys 56corresponding to the default field are inverted. Thereafter, thehandheld interface waits for an event to occur (step 1816 in FIG. 7a)and when it occurs, identifies the event number corresponding thereto.

[0081] Processing flows along one of six paths depending upon whichevent number is identified. While each field upon the vitals screencorresponds to a separate event number, the events as displayed in FIG.8 may be grouped into six general categories, namely, touching a rollkey, touching the icon, touching the scroll bar, touching the patient'sgeneral information, touching the escape key, and touching the changescreen buttons (blocks 1818, 1830, 1840, 1852, 1858 and 1864). Once theevent number is identified as corresponding to a rolling key 56, it isdetermined whether the touched rolling keys are active (step 1819). Ifnot active, processing returns to step 1816. If active, a pointer isdetermined which identifies the field within the workspace memory 202which corresponds to the specific roll key/vital sign selected (step1820).

[0082] Next, the data value identified by the pointer into the workspaceis incremented by a 1, 10, 100, etc. depending upon the rolling keywhich was touched (step 1822). Thus, referring to FIG. 3c, if the userpresses the center rolling key corresponding to the systolic field, thesystolic data value within the workspace memory will be incremented by10. Similarly, if the diastolic field is selected and the user pressesthe leftmost rolling key therein, the processor will increment thediastolic data value within the workspace memory by 100. Next, it isdetermined whether or not the incremented value has created an overflowand if so, the incremented digit is rolled-over (step 1824). Thisrollover function is performed to rotate a rolling key having a currentvalue of 9 to a new value of 0.

[0083] Thus, if the user selects the pulse vital and contacts the “Is”rolling key (which has a present value of 9), the processor will updatethe pulse value within the workspace memory to “80”. Thereafter, the newvital sign is drawn into the rolling keys 56 which have been updated andthe new vital sign is stored in the corresponding field in the workspacememory (step 1824). Finally, the processor updates the scroll bar 58 toreflect the change in the current data value (step 1826).

[0084] If the event identified in step 1816 corresponds to an icon,processing proceeds to step 1830. First, the rolling keys aredeactivated for the previously active vital sign field (step 1832) andthe rolling keys for the newly chosen vital sign are activated (step1834). Next, the rolling keys for the deactivated and newly activatedvital sign fields are inverted to display the newly active field to theuser (step 1836). Thereafter, the scroll bar 80 is redrawn withparameters, ranges and current vital signs corresponding to the newlyselected vital sign field (step 1838).

[0085] When the identified event corresponds to touching the scroll bar80, process flows to step 1840. Once the scroll bar is touched, theexact location of the event is determined therein and used to identifythe corresponding vital sign value (step 1842). Then, a pointer isdetermined which identifies the vital sign data value within theworkspace memory which corresponds to the active vital sign field (step1844). This vital sign data value is updated to the new vital sign valueselected within the scroll bar (step 1846). Thereafter, the activescroll keys are updated with the new data value (step 1848) and thescroll bar is inverted to reflect the new data value (step 1850). Whenthe event occurs within the patient information region, processing flowsto step 1852. In such a case, the patient information screen is redrawn.To do so, a calling identifier is set to correspond to the patientinformation screen (step 1854) and control is returned to the main loop(step 1856).

[0086] Optionally, when the user touches the patient information region,a pop-up window may appear and query the user as to whether it isdesirable to go to the patient information screen or enter a patientidentifier through the bar code reader. In either case, if the usertouches the patient information region, before new patient vital signshave been transmitted to the communication server, the user is promptedas to whether or not these vital signs should be transmitted. When theescape icon is touched, processing flows to step 1858, after which thecalling identifier is set to zero (step 1860). Processing is returned tothe main loop (step 1862).

[0087] If the screen changing buttons are touched, processing flows thento step 1864, after which the selected button is determined (step 1866).In step 1867, it is determined whether the event corresponds to thetransmit button. If the selected button corresponds to the transmitbutton, the current patient vitals are constructed into a packet formatand transmitted to the communication server 12 (step 1868). If theselected button does not correspond to the transmit button, the callingidentifier is set equal to the newly selected screen (step 1870).Thereafter, control is returned to the main loop (step 1872).

[0088] When the return code within the main loop is set to correspond tothe view graph display screen (FIG. 3d), the processor determines theactive vital sign field (e.g., systolic field), and obtains thecorresponding default parameters for the graph. Thereafter, the screenis cleared and a graph having the parameters for the active vital signfield is drawn. Next, the vital sign data values for the active vitalsign field are read from the workspace memory and used to draw thegraph.

[0089] Optionally, in the view graph screen a series of changingfunction buttons may be displayed along the bottom thereof. Thesebuttons would allow the user to automatically select another vital signto view in a graph format without intermediately returning to the vitalinput screen.

[0090] In accordance with the above procedure, the handheld interface 8allows for user inputs and displays patient information to the user.

[0091] Interface-Server Protocol

[0092] Once the user enters the desired data and wishes to send thisdata to the communications server 12, the user presses the transmitfunction button 70. Once the CPU 32 identifies that an event hasoccurred which corresponds the transmit function button 70, the mainloop (FIG. 4) calls the transmit handling function. FIG. 4 illustratesthe process by which the CPU 32 transmits data to the communicationsserver 12.

[0093] As illustrated in FIG. 9, each transmission comprises aninformation packet 300 of IR signals corresponding to a packet of data,wherein every packet is constructed with the same predetermined length(e.g., 128 bytes) and in one of two formats. This length is software andoperative system definable and may vary. Certain messages transmittedbetween the handheld interfaces 8 and the corresponding communicationservers 12 comprise an amount of data which is unable to be assembledinto a single packet. Thus, in such circumstances the transmittingdevice segments the data into a plurality of equal length packets 300(referred to as frames). The series of frames form a message 302.

[0094] When transmitting a message the first packet/first frame thereofis constructed with a header section 304 formed in a long headerstructure followed by a data field 306. The long header 304 includes a 4byte command field 308, a 6 byte user identifying field 310, and a 4byte message total field 312. The command field 308 identifies theprocess to be performed upon the subsequent data, the user ID identifiesthe user signed into the handheld interface 8 transmitting or receivingthe packet 308 and the message total 312 identifies the total length ofthe message which will follow. This total length includes all byteswithin subsequent packets 300 corresponding to this specific message302. Thereafter, a data field 314 (having 114 bytes in a packet with a128 byte structure) follows.

[0095] If the message includes more data than will fit in a singlepacket, subsequent packets/frames are transmitted. These subsequentpackets/frames are constructed with a short header structure 316preceding the data segment 318. The short header 316 includes a 4 bytecommand 320 and a 4 byte positioning packet 322 identifying number toenable the receiving device to determine the position of the packetwithin the overall message. Packets containing a short header 316includes a 120 byte data field for a packet formed with 128 bytes.During transmission, the first packet of each message includes a longheader 304 structure followed by a data field, with each subsequentpacket within the message including a short header 316 instructedfollowed by a data field. In this manner, the device is able to increasethe amount of data transmitted within each packet for long messages. Thetransmitting device need not send the user ID and the message total morethan once for a given message since the receiving device is able toassociate corresponding packets with a single message 302 based on thepacket number 322 and communication channel.

[0096] To transmit a message (FIG. 10), the CPU 32 reads the currentdata from the workspace memory 200 in the RAM 35 (step 400). Next, theCPU 32 determines the length of the message and the ID of the usersigned in to that handheld interface 8 (step 402). The CPU 34 constructsa packet header formed with the long header structure (step 404). TheCPU 34 clears the packet number (step 406) and writes the data to thetransmit buffer (step 408). If the packet is full (step 410), the CPU 32transmits the packet and clears the buffer (step 412). If the packet isnot full, it determines if more data exists to write to the buffer (step414). If no more data exists, it transmits the packet. If more dataexists, it again writes to the packet. In step 416, it is determined ifmore data exists, and if not it exits. If so, the packet number isincremented (step 418). Next, the CPU 34 constructs a partial shortheader for the second frame to be transmitted in this message (step420). The partial header includes the code for the corresponding commandand the current packet number. Thereafter, the next segment of data iswritten to the packet (step 408) and steps 410 through 420 are repeated.Once the last packet is transmitted (step 414) and it is determined thatno more data remains to be written to the packet (step 416), the systemexits the transmit routine (step 422).

[0097] Communication Server

[0098]FIG. 16 illustrates a block diagram of the communication server12. The communication server 12 includes an IR receiver/transmitter 100which receives and transmits IR communication packets from and to thehandheld interface 8. The IR receiver transmitter 100 operates inconjunction with an I/O card 102 to store a packet of information fromeach communication channel in the corresponding address within atemporary buffer 104. Each communication channel corresponds to a uniquehandheld interface 8. For instance, the communication server 12 mayprovide for 128 IR channels and thus, the temporary buffer 104 willinclude 128 buffer locations, with each buffer location havingsufficient memory to store a complete IR packet 300 (FIG. 9). The numberof channels is locally definable and may be any desired number. Thearray locations within the temporary buffer 104 store the IR packets inthe format transmitted from the handheld interface 8 as described above.

[0099] The communications server 12 further includes an input buffer 108which represents a storage space used by the CPU 106 when convertingpackets from the format stored in the temporary buffer 104 to messagelists with a different format to be transmitted to the command servers14. The input buffer 108 represents an array, each element of whichincludes the COM_INFO structure (explained below).

[0100] Each element of the input buffer 108 array is accessed based onthe device number. Thus, if 128 handheld interfaces 8 are being used,the input buffer 8 will include 128 elements. The communications server12 further includes a message buffer 110 which is utilized to store theactual data for each complete message sent from the hand held interfaceonce all of the necessary packets have been transmitted by the handheldinterface 8 and reassimilated by the CPU 106 into a single message. TheCOM_INFO stored in the input buffer 108 includes a pointer MSG_From_HHinto the message buffer to the beginning of the corresponding datastring. Once every packet 300 for a message 302 is received and thecorresponding data is stored in the message buffer and the COM_INFO isstored in the input buffer 108, the CPU 106 constructs a message listtherefrom. Each message list to be processed by the command server 14 isstored on one of a process queue 114. The message list includes apointer to the corresponding data string in the message buffer 110. Eachmessage list received from the command server 14 is initially stored ina transmit queue 116 prior to being converted back into packets 300 andtransmitted to the handheld interface 8. The message list includes apointer to a corresponding data string which is stored in the messagebuffer 110 when it is received from the command server 14.

[0101] The process and transmit queues are operated in afirst-in-first-out sequence such that each message is processed ortransmitted in the order in which it is placed in the queue. Thetransmit and process queues 112 and 114 constitute dynamic queuingsystems which attach message lists in a linked list structure. Eachmessage list include the data structure illustrated below: MESSAGE LISTCOM_(—) Data Com- MSG_TO_HH MSG_LEN Prev INFO File mand (Pointer) (LongMSG_LST 10 (In- (1) Integer) (Pointer) teger) COM_INFO Device CMD PacketUser ID User MSG MSG MSG Number (4) Number To ID Total Length From(Integer) (Long (6) From (Long (Long HH Integer) (6) Integer) Integer)(Point- er)

[0102] The message list data structure includes a first section COM_INFOdedicated to, and containing information concerning, messages receivedfrom the handheld interface 8. The next four fields represent fieldswhich are created immediately before transmitting a message list to thecommand server 14 and another communications servers 12. The final field(Previous MSG_LST) is used as a pointer to the subsequent message listwithin the queue to be processed. The first section COM_INFO includes adevice number uniquely identifying the handheld interface transmittingthe message. The device number is generated by the I/O card 102 when theCPU 32 requests a packet 300 from the temporary buffer 104. The devicenumber is produced depending upon the communications channel beingaccessed. The command (CMD) includes the structure of the CMD fieldtransmitted in the header of each packet 300 (i.e., the 2 byte databaseID, 1 byte command ID, and 1 byte reserved).

[0103] The command (CMD) represents the command to be processed inaccordance with the corresponding message being transmitted to or fromthe handheld interface 8. The 4 bytes within the command are separatedsuch that the first two bytes identify the database to be processed whenperforming the command, the third byte stores a number corresponding tothe specific command to be performed, and the fourth byte is reserved.By way of example, with respect to the third byte, numerals 1-127represent commands to be processed by the command server, while numerals128-255 represent a command from the handheld interface 8. As notedabove, the use of shorthand code numbers for specific commands reducesthe amount of data to be transmitted to and from the handheld interface8.

[0104] The Packet Number is a long integer which is incremented eachtime a packet is appended to a message on the input buffer 108. TheUser_ID_To is a 6 byte value added by the handheld interface 8 toidentify a destination user. If set to zero, the destination is thecommunications server. The communications and command servers determinewhich server to send the command to. This value if non-zero willidentify the user of a handheld interface 8 desiring to communicatetherewith. The User_ID_From is a 6 byte value added once at login time.This user ID is assigned to the channel to identify who is logged in atthat channel. This value is maintained until the person signs out. Thus,the user ID will only be transmitted once during a login session. Thecommunications server 12 keeps track of each User ID signed ontohandheld interfaces served by that communications server 12. The messagetotal length (MSG_Total) is a value assigned by the handheld interface 8or by the command server 14 when a message is transmitted. The messagelength (MSG_LEN) is a value updated by the short and long header parsingfunctions to keep track of the length of a message in the message buffer110 as the packets for the message are added thereto. The message lengthfield is initially tested by the communications server 12 whenprocessing each packet in the temporary buffer 104 to determine if thepacket is in a long or short header form. The message pointer field(MSG_From_HH) is a pointer into the message buffer to the location ofthe actual data message. The MSG_From_HH pointer is updated each time anew packet is appended to a message.

[0105] The message list structure includes the above COM_INFO structureas in addition to a Data_File field that represents an integeridentifying the database, written from the COM_INFO structure, to beprocessed in connection with the corresponding command. The command(CMD) field represents a one byte command, written from the COM_INFOstructure, to be processed. The MSG_To_HH field represents a messagepointer used to point to the data compiled by the command server inconnection with this message which will ultimately be sent to thehandheld interface 8. The MSG_LEN field represents a long integeridentifying the current length of the data corresponding to the messageand stored in the message buffer. The Previous_MSG LST represents apointer pointing to the next message to be processed. The previousmessage pointer enables the system to accomplish dynamic queuing for theprocess and transmit queues.

[0106]FIG. 11 illustrates the processing sequence by which thecommunication server 12 receives messages from the handheld interface 8,processes these messages and transmits these messages to the commandserver 14. First, the I/O card 102 is initialized, along with thecommunication channels, buffers and queues (step 700). Next, the datastructures for the message list, COM_INFO, CMD, and short and longheaders are set up (step 702). A current channel to be read by the I/Ocard 102 is initialized to the first channel (step 704). Next, thecurrent channel is tested to determine whether data is being transmittedthereon from the corresponding handheld interface 8 (step 706). If datais present, the packet of transmitted data is read and stored in thetemporary buffer 104 (step 708). The packet of data is stored within thetemporary buffer 104 at the array address corresponding to the currentchannel. A channel identifying number corresponding to the transmittinghandheld interface 8 is also assigned thereto by the I/O card 102.

[0107] Next, a check sum field within the data packet is tested todetermine whether the transmitted data is valid (step 710). If the datais invalid, the communication server takes the necessary correctiveactions (step 712). If the data is valid, the CPU 106 requests thechannel number (step 714) and the packet 300 from the I/O card 102 andutilizes the channel number to index the correct corresponding elementwithin the input buffer 108. Next, it is determined whether a packet isan initial frame or a subsequent frame of a message (step 716). Toeffect this test, the message total field, within the element of theinput buffer 108 corresponding to the current channel, is read andcompared to zero. If the message total field equals zero, then a packethas not yet been written to this element of the input buffer 108. Thus,the packet being read is identified as an initial packet which willinclude the long header structure. Otherwise, the packet is identifiedas one containing the short header structure. In either case, the packetnumber is incremented within the currently indexed element of the inputbuffer 108.

[0108] If the packet contains the long header structure, processingmoves to step 718 in which the parse long header function is invoked. Ifthe packet includes the short header structure, processing moves to step720 where the parse short header function is invoked.

[0109]FIG. 12 and FIG. 13 illustrate the parse long and short headerfunctions. Within the parse long header function, the first four bytesof the data packet within the temporary queue is read as the command(step 722). This command is compared with a list of valid commands andif the command is invalid the processor takes the necessary correctiveaction (step 724). If the command is valid, the command is written tothe command field within the element of the input buffer 108 indexed bythe corresponding channel number (step 726). Next, the subsequent sixbytes of the packet within the temp buffer is read as the User ID, ifpresent, of the destination user for the attached message/data. This sixbyte ID is stored in the User ID_To field of the element within theinput buffer 108 indexed by the current channel number (step 728). TheUser ID, corresponding to the signed on user, is added to theUserID_From field of the indexed element.

[0110] Next, the subsequent four bytes are read from the packet withinthe temporary buffer 104 as the total length of the following message(e.g., the total number of bytes to follow within one or more packetscorresponding to the present message) (step 730). The four byte valuerepresenting the message total is converted to a long integer (step 732)and assigned to the message total field within the element of the inputbuffer 108 indexed by the current channel number (step 734). Thereafter,the data section within the packet is written to the message buffer as adata string and the length thereof is stored within the message lengthfield within the presently indexed element of the input buffer 108 (step736).

[0111] A message pointer pointing to the data string within the messagebuffer 110 is stored within the message pointer field of the indexedelement within the input buffer 108 (step 738). Finally, the element ofthe temporary buffer 110 is cleared (step 740). In this manner, steps718-740 parse through a packet having a long header structure, createthe COM_INFO structure within the input buffer 8 and store the message302 from the handheld interface 8 within the message buffer 110.

[0112] Returning to FIG. 11, if in step 716 it is determined that thepacket is not an initial packet, then the short header function isinvoked (see FIG. 13). First, the first four bytes of the packet arepulled (step 742) and compared with the value in the command field ofthe currently indexed element within the input buffer 108 (this commandis indexed based on the channel number) to determine if these commandsare the same (step 744). If not, the system takes the necessarycorrective actions (step 746). If the commands correspond, the packetnumber within the short header is pulled (step 746), converted to a longinteger (step 748) and compared to the packet number (plus one) withinthe indexed element of the input buffer 108 (step 750). These packetnumbers must correspond to ensure that the received packet is the nextpacket to be added to the input buffer 108. If the packet numberscorrespond, the present packet is identified as part of the messagecorresponding to the presently indexed element within the input buffer108 and processing flows to step 752, else it returns. If the packet isnot matched based on above criteria, then a corrective action is taken.

[0113] Next, the data within the temporary buffer 110 is pulled (step752) and the portion of the message already stored in the message buffer110 is read (step 754). The new data is added to the end of the storedmessage and the new total string is rewritten to the message buffer 110(step 756). The message pointer (MSG_From_HH) and the message length(MSG_LEN) are updated within the corresponding fields of the COM_INFO ofthe indexed element of the input buffer 108 (step 758). Thereafter, thecontrol returns to the main process (step 760).

[0114] Referring to FIG. 11, once control is returned to the mainprogram, the current channel is incremented (step 760). Next, it isdetermined whether all channels have been checked (step 762). If so,control is set to the processing sequence (at point A). If all of thechannels have not been checked, control returns to step 706. Thisprocess is continuously performed until all of the channels have beenchecked thereby transferring all packets of data from the temporarybuffer 104 to the input buffer 108 and message buffer 110.

[0115] Next, processing moves to the processing queue sequence (FIG. 14)to move completed messages 302 to the processing queue 112. First, thecurrent element pointer into the input buffer 108 is set to the firstinput buffer element (step 800). Then, it compares the message totallength (MSG_Total) with the message length (MSG_LEN) to determinewhether a complete message corresponding to the current element withinthe input buffer 108 has been received and stored in the message buffer(step 802). If not, the incomplete message remains on the input buffer108 and the current element pointer is incremented (step 804) and theprocess returns to step 802.

[0116] If the complete message for the current element has beenreceived, the message is placed on the processing queue (step 806) bycreating a message list therefor. To do so, the command information(COM_INFO) of the current element of the input buffer 108 is written tothe processing queue 112 and stored in the command information(COM_INFO) section therefor. As the corresponding message represents atransmission from the handheld interface 8 to the command server 14, thenext four fields of the indexed message list element in the processingqueue remain undefined. This message list is “pushed onto the back” ofthe processing queue by storing, in the preceding message list in theprocessing queue, a pointer to the current message list. This pointer isstored in the final field (Previous_MSG_LST) within the previous, mostrecent message list added to the processing queue (step 806).

[0117] Once the command information has been moved to the processingqueue, the corresponding element of the input buffer 108 is cleared(step 808). Thereafter, the current element pointer into the inputbuffer 108 is incremented (step 810) and it is determined whether or notevery element of the input buffer 108 has been tested (step 812). Ifnot, processing returns to step 802 and the next element within theinput buffer 108 is processed. If processing is done on the input buffer108, control moves to the process the message lists on the processingqueue.

[0118] The first element of the processing queue is tested to determinewhether a command is stored therein (steps 900 and 902). If a commandexists on the processing queue, this command is “dequeued” (step 904) byreading the message information from the processing queue (which isstored in the message list structure). The command field (CMD) withinthe COM_INFO section of the message list is read. The message is parsedinto specific components (step 906), by reading the first two bytes ofthe command field, converting these bytes to a long integer form andstoring the data base identifier in the Data_File field of the messagelist (step 908). Next, the third byte of the command (CMD) field in theCOM_INFO structure is read and stored in the Command field of themessage list (step 910). Then the actual data message is appended to themessage list structure based on the message pointer (MSG_TO_HH) and themessage length (MSG_LEN) are reset (step 912). The communications server12 sends the message to the appropriate command server 14 based upon thedatabase and command code (step 912).

[0119] Next, the previous message pointer (Previous_MSG_LST) is readfrom the current message list to determine the next message to beprocessed on the queue (step 914) and control is returned to step 902.In this manner, each message upon the processing queue 112 is parsedthrough and transmitted to the appropriate command server 14. When nomore commands are on the processing queue, control is moved to thecreate transmit queue module (step 916) (FIG. 15).

[0120]FIG. 17 illustrates the process by which the communication server12 processes messages upon the transmit queue which are to be sent tothe handheld interface 8. First, the first message upon the transmitqueue is tested (step 1000) to determine whether data is containedtherein (step 1002). If data exists, the message is dequeued by takingthe message off the transmit queue (step 1004). Next, the commandinformation from the message list is read and a long header constructedfor the first packet to be transmitted to the handheld interface 8 forthe message (steps 1008 and 1009). Next, the data from the message iswritten to the packet and transmitted (step 1010 and 1012). Thereafter,it is determined whether additional data remains to be transmitted tothe handheld interface 8 (step 1014). If yes, a short header isconstructed (step 1015) and additional data from the message is writtento the packet containing the short header (step 1016).

[0121] Once constructed, the packet containing the short header istransmitted (step 1018) and processing returns to step 1012 at which itis determined if more data remains. This loop is repeated until theentire message has been transformed from the message list structure intodata packets and transmitted to the handheld interface 8. Once theentire message has been transmitted, control passes to the next module(step 1020).

[0122] The communications server 12 tests the communication bus 6 anddetermines if messages have been sent from other communication servers.First, the communications bus is tested to see if a message exists (step1100). If a message exists, the message is read (step 1104) and thecommand therefor is decoded (step 1106). Thereafter, the command istested to determine whether the message should be transmitted to acorresponding handheld interface 8 or whether the message should betransmitted to a command server connected to the communication server 12(steps 1108 and 1110). Thereafter, the message is placed on the transmitor processing queue depending upon the destination of the message (steps1112 and 1114). Thereafter, control is returned to the main program(step 1116). This process is continuously repeated until thecommunication server 12 is turned off. Once turned off, thecommunications channels are closed and the system is turned off.

[0123] Command Server

[0124] The command server operates to update the corresponding databasesbased upon messages received from the communications server. The commandserver utilizes a conventional software package for managing thesedatabases, such as Pro-tree (version 2.0). Other database managingsystems may be used to access the data base, such as DBase, CodeBase,B-Trieve, Cisam and the like. Particular commands within theconventional management system are called depending upon the commandcode and database codes transmitted within the message list.

[0125]FIG. 19 illustrates the process by which the command server 14invokes the database management functions. First, the command server 14receives a message (step 900), including the complete message liststructure followed by the data message. Next, the command server 14reads the data base file field (step 902) and determines whether thatdata base code is valid for the present command server 14 (step 904). Ifnot, it returns an error message (step 906). If so, control istransferred to the database routine corresponding to the command code(CMD) in the Command field of the message list (step 908). Next, it isdetermined whether the command code is correct for the addresseddatabase (step 910). If not, it returns an error code (step 906). If so,it accesses the message data within the message list and performs theappropriate operation upon the data base (step 912). Thereafter, itconstructs a return message using the data returned from the databaseinto the structure of the message list (step 914) and quits (step 916).

[0126] To invoke the database managing functions, the command number isprocessed within a case statement, whereby each case within the casestatement corresponds to a unique command number. Each case statementcalls the appropriate routines. For instance, command number 7 mayrepresent an add command, and thus, case “7” would direct the commandserver to read the data from the message and write this data to the nextaddress within the database. Similarly, the command number within themessage may represent a read or request operation, in response to which,the corresponding case would direct the command server to read thedesired information from the database corresponding to the user IDtransmitted within the message. The command server thereafter adds thisdata to the message and retransmits it to the communications server.

[0127] From the foregoing it will be seen that this invention is onewell adapted to attain all ends and objects hereinabove set forthtogether with the other advantages which are obvious and which areinherent to the structure.

[0128] It will be understood that certain features and subcombinationsare of utility and may be employed without reference to other featuresand subcombinations. This is contemplated by and is within the scope ofthe claims.

[0129] Since many possible embodiments may be made of the inventionwithout departing from the scope thereof, it is to be understood thatall matter herein set forth or shown in the accompanying drawings 1-19is to be interpreted as illustrative, and not in a limiting sense.

[0130] The following appendix sets forth descriptions of the modules andfunctions used by the present system.

[0131] Glossary

[0132] key—an area of the screen that has been registered with theopening system as an area where an event is expected. If an event doesnot occur within this area, an integer identifier will be returned bythe operating system indicating that the event did occur.

[0133] event—the screen was touched, if it was touched in an areadefined by a key, then return the identifier.

[0134] scrolling text window—a key where scrolling text will reside.

[0135] scroller—a key associated with the scrolling text window, thescroller has a bar in it to indicate where the text within the textwindow is in relationship to the rest of the text.

[0136] scrollbar—the tool used for entering vitals (darkened from thevery bottom of the key to the value chosen by the user).

[0137] rolling key—a key with a digit in it, when the key is touched,that digit is incremented. If the digits value is 9 and it isincremented, it will contain the value 0 with no carry performed.

[0138] Module

[0139] scrollbar.c—contains all functions for the scroll bar functionsto be used by other modules.

[0140] init_scroll_bar—initializes all necessary variables and draws allof the detail.

[0141] get scroll_bar_value—upon an event in the scroll bar key, thisroutine is called and it handles that event, then it returns the valueand that the scroll_bar is pointing to (the value point pointed to bythe user).

[0142] set_scroll_bar_value—the user can set the value anytime.

[0143] functions to be used internally by this module

[0144] draw scroll_bar—draws the inside of the scroll bar.

[0145] Module

[0146] vital_input—contains all the functions used to perform the vitalinput

[0147] note—the Mode value indicates what is being input at the moment,if the user has chosen systolic, then the systolic rolling keys areinverted and activated, and the scroll bar will have the systolic datain it.

[0148] possible modes—systolic, diastolic, pulse, temperature,respiratory.

[0149] Write_Keys_Data—this routine redraws the rolling keys associatedwith a certain mode, (example, if the mode is pulse and the user somehowchanges the value, this routine draws the 100s value in the leftmostkey, the 10s value in the middle key, and the Is value in the rightmostkey):

[0150] ChangeMode—changes the mode of the screen, this involves (1)turning off the old mode (example—pulse); (2) turning on the rollingkeys of the new mode (example—systolic) so now an event may occur——alsoinvert the keys to that they are white on black; and (3) calling

[0151] Init_scroll_bar to redraw the scroll bar with the new modesdetails.

[0152] EnterVitalsDraw—draw the detail on the entire screen

[0153] (1) write patients name

[0154] (2) write last date and time that the vitals were entered

[0155] (3) write the last vitals values

[0156] (4) turn off all rolling keys

[0157] (5) change the mode to systolic by calling changemode

[0158] inc_value—increment the values in the rolling keys, then callWrite-Keys_data.

[0159] inc_temp—same as inc_value, but allow the 100's key to containthe values 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11.

[0160] Do_vital_input—THE MAIN ROUTINE

[0161] (1) calls EnterVitalDraw

[0162] (2) contains the case statement that handles events.

[0163] Module

[0164] graph.c——draws the graph on the screen.

[0165] make_graph—receives x, y values, x axis label, y axis label, thetype of data that the x and y values are (time, short int, int, longint, float, etc.) and draws the graph, depending upon the type of datain x and y, it calls a simple routine that turns the x, y values into x,y plotting points on the screen.

[0166] Module

[0167] patinput.c——contains all of the functions used to pick a patient.

[0168] DoPatientInput—does the entire screens functionality within thisone routine.

[0169] 1—init_scroller—passes in the patient list and the two keys(scroller key and scrolling text key).

[0170] 2—handles all events.

[0171] events

[0172] in the case that the user picks A-Z, that letter is

[0173] concatenated onto the search string which is initially empty,then a sequential search upon the text strings is performed to find thefirst text which is greater in alphabetic value than the search string,then that value is chosen via the function set_scroller_value.

[0174] in the event the user touches the scroller then

[0175] get_scroller_value is called.

[0176] in the event the user touches the scrolling text key, thenget_scroll_text value is called.

[0177] Module

[0178] vital_(—)1.c——the starting point of the program contains allfunction calls.

[0179] note——Every single “screen” that is called from any other“screen” will be associated by a Calling Identifier (Call ID).

[0180] DoMainMenu—two main case statement

[0181] case statement #1

[0182] handles the events of the main menu, if an event occurs in any ofthe keys of the main menu, then store the CallID in the variable calledReturnCode.

[0183] case statement #2

[0184] while ReturnCode is not equal to 0 loop the case statement. sincethe ReturnCode is not 0, call the appropriate function associated withthe Calling Identifier stored in the variable, the function called willeventually return a code that will again be stored in the variableRetCode.

[0185] Module

[0186] scroller.c—contains all functions for the scrolling text windows.

[0187] functions to be used by other modules

[0188] init_scroller—initializes all necessary variables and draws ofall the detail.

[0189] get_scroller_value—upon an event in the scroller key, thisroutine is called and it handles that event, then it returns the valuethat the scroller is pointing to (in our program, this value is theindex into an array of strings—points to the text that was picked).

[0190] set-scroller_(—)

[0191] value—the user can set the value any time

[0192] get_scroll_text_value—upon an event in the scroll text window,this routine is called and it handles that event, then it returns thesame value as does the get scroller_value function. functions to be usedinternally by this module

[0193] draw_scroller—draws the bar inside of the scroller, then callsdraw_scroll text.

[0194] draw_scroll-text—draws all of the text that appears in thescrolling text window.

[0195] invert_picked_text—inverts the text that is being pointed to bythe user.

[0196] Major Functions:

[0197] open_ir—used to initial the IR communication with the AndroDatCard and setup the communication channels with each device.

[0198] close_ir—used to close all communication channels with the handheld.

[0199] init_com_info—used to reset and clear all data contained for onespecified com) info buffer. This routine is called initially toinitialize each buffer and ready to receive data. After a message hasbeen received and put on the process queue, this routine is used toclear the old data and read the input buffer for the next command.

[0200] collect_messages—this routine will read through each inputchannel to see if a message exists. If one exists, then the message willbe read into a temporary buffer and passed to the routine place_messagefor placement on the input buffer.

[0201] place_message—this routine will determine if the message beingread is the first or subsequent message. If the message is the firstpacket, then the routine parse_long_hdr is called. If the packet is thesecond or subsequent message, the routine parse_short_hdr is called.

[0202] parse_short_hdr—this routine is used to parse the structuretmp_buffer, validate the command being sent along with the correctpacket number, then place the data in the appropriate in_buffer messagestructure. This routine is called after the initial command packet issent.

[0203] parse_long_hdr—this routine is used to parse the structuretmp-buffer, validate the command being sent. This routine theninitializes the in_buffer structure and finally places the data in thein_buffer messages structure. This routine is called when a handhelddevice sends its initial packet for requesting a command.

[0204] comm_server—this routine is the main routine which controls thelogic flow of the entry communication server system.

[0205] process_in_buffer—this routine is used to search the in-bufferfor completed messages to be placed on the process queue. This routinedetermines if a message is finished if msg_total=msg_len andmsg_total >0. This routine calls ENQUEUE to physically put the messageon the process queue.

[0206] process_(—)

[0207] cmd—this routine is used to take the next message off the commandqueue then send it to the correct server for processing. This routinecalls the dequeue function to physically dequeue the item off thecommand queue.

[0208] process_transmit—this routine is used to take the next messageoff the transmit queue then send it to the correct server forprocessing. This routine calls the dequeue function to physicallydequeue the item off the transmit queue.

[0209] packet_msg—this routine is used to physically send the messagefrom the communication server to the handheld computer via the AndroDatCard. It is responsible for all packets of the data and verify ofsuccessful transmission.

[0210] enqueue—this routine takes completed messages and places them onthe queue. A parameter is passed to which queue to place the messagealong with the data to queue.

[0211] dequeue—this routine will take messages off the queue and placethem in a temporary buffer to be processed by the communication server.A parameter is passed to which queue to process along with the temporaryspace to put message.

[0212] nulqueue—this routine is used to initialize a queue and prepareit to start receiving data. Call to this routine will destroy any dataexisting in the queue.

[0213] com_info—this structure is used to store the incoming messagefrom the handheld

[0214] in_buffer—this is an array of the structure com_info. Thisstructure is used to hold the individual messages being received fromthe handheld computers.

[0215] message_list—this structure is used to serve as the queuingfunctions for the command processing and data transmission.

[0216] long_dr—this is the structure of the header for initialcommunication to the server.

[0217] short_hdr—this is the structure for second and subsequentcommunications of the second command.

2. A handheld portable data terminal having an integrated code readerfor data entry and a graphical user interface for interacting with auser to enter user-supplied information, wherein the graphical userinterface includes: multiple virtual regions displayed on a displayscreen, wherein each virtual region corresponds to an event identifier;a touch screen for sensing location of user contact; and an eventhandler for identifying one of the virtual regions that corresponds tothe location of user contact, determining a specific event identifiercorresponding to the identified virtual region, and processing apredetermined sequence for the specific event identifier.
 3. Thehandheld portable data terminal of claim 2, further comprising awireless communication interface for communication with a remotecomputing device over a wireless communication channel.
 4. The handheldportable data terminal of claim 2, wherein the code reader comprises anoptical bar code reader.
 5. The handheld portable data terminal of claim2, wherein the data comprises product information.
 6. The handheldportable data terminal of claim 2, wherein the data comprisesinformation identifying a medical patient.
 7. The handheld portable dataterminal of claim 2, wherein the data comprises information related amedical patient.
 8. The handheld portable data terminal of claim 7,wherein the data comprises one of personal information gathered uponadmittance for care, information related to past medical history of themedical patient, and information related to vital statistics of themedical patient.
 9. The handheld portable data terminal of claim 8,wherein the vital statistics include one of systolic, diastolic, pulse,temperature and respiratory information.
 10. The handheld portable dataterminal of claim 2, further comprising a wireless communicationinterface, that operably couples the data terminal to a remote computerand associated information database via a wireless communicationchannel.
 11. The handheld portable data terminal of claim 10, furthercomprising local memory storing information loaded from the informationdatabase via the wireless communication interface.
 12. The handheldportable data terminal of claim 10, wherein the user-suppliedinformation is communicated to the remote computer over the wirelesscommunication interface for storage in the information database.
 13. Thehandheld portable data terminal of claim 10, further comprising amessage notification mechanism that notifies the user of receipt ofmessage from the other computing device over the wireless communicationchannel.
 14. The handheld portable data terminal of claim 13, whereinthe message notification mechanism generates one of an audio signal,video signal and vibration signal.
 15. The handheld portable dataterminal of claim 2, wherein the graphical user interface furthercomprises a virtual keypad displayed on the display screen for enteringsymbols associated with keys of the keypad.
 16. The handheld portabledata terminal of claim 2, wherein the graphical user interface furthercomprises at least one scroll bar displayed on the display screen. 17.The handheld portable data terminal of claim 2, wherein the graphicaluser interface further comprises at least one scroll bar format and arolling key format.
 18. The handheld portable data terminal of claim 2,wherein the graphical user interface further comprises a menu screen anda graphing screen, wherein each selection from the menu screencorresponds to a virtual region and an associated processing sequence.19. The handheld portable data terminal of claim 2, wherein each virtualregion of the graphical user interface corresponds to a predefinedprocessing sequence which is initiated by the user by contacting theassociated virtual region.
 20. The handheld portable data terminal ofclaim 19, wherein the predefined processing sequence involves one of adata entry operation, a data transmit operation that communicates datastored thereto to another computing device, and a code scan operationfor data entry.
 21. The handheld portable data terminal of claim 15,wherein the graphical user interface further comprises a display screendisplaying multiple icons.
 22. The handheld portable data terminal ofclaim 2, wherein the graphical user interface comprises a text inputmechanism that enables the user to enter at least a portion of a desiredtext data, that automatically searches data stored in memory to retrievetext data closest to the portion of desired text data entered, anddisplays the retrieved text data on the display screen.